Where do these components stand with regards to other mapping techniques?

We have seen different mapping solutions in other lessons of this course : with a webviewer, with start activity, with fusion tables and with static maps

• mapping with a webviewer is the easiest and enables interactive display, but your app does not see map events (clicks, ...) and there is no data feedback (or very little): this is a good "map output only" solution.
• mapping with start activity is similar : your app loses control to an other app (that runs on your phone). It brings more complexity, may be with a few more functions (I don't like it, it's too difficult to explain).
• mapping with static maps (usually Google API) displays maps as the backround image of a canvas. This keeps full app control on events, including clicks, sprite collisions, ... It's one of my favorites. The problem is that you need to write all the code, including coordinate conversions from pixels to meters and degrees of latitude and longitude.
• mapping with fusion tables uses a webviewer (as for the first case) but with a powerful server that cnnects mapping functions and data management (SQL like). That means you can click on objects to display their properties, but cannot drag objects nor catch click events from your app. Map interactions stay on the server side.

So where are we with the App Inventor mapping components ? somewhere between mapping with static maps in a canvas and mapping with fusions tables.

• We keep a high level of interactions within the app (clic, long clic, drag, ... objects) as is the case with static maps :
  • what we loose are the sprites and balls, real time move and their collisions,
  • what we gain is huge : sructured data management in the geographic space.
• We get a new level data management
  • user handles data in the geographic space (not in screen pixel space), with embedded functions to zoom and pan,
  • data are handled as geographic objects (features) with geometric properties (point, lines, areas, ...) and semantic or descriptive properties. This enables high level exchanges (feature, or feature collection level) with geographic databases, using the GeoJSON format
  • there is at least one level of abstration above the sanvas/staticmaps approach,
  • processing is done "locally" i.e. on the smartphone, which means less dependency on internet and servers,
  • However, there is no database management functions, as is the case with fusion tables. Apps will need to use a local or network database.

Last but not least, if you intend to become a high level user of geographic data this will teach you basics that are shared by geoData/GIS professionals.